• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    A system and method is provided for predicting passenger loads at vehicle stops on a transportation network. The method includes providing a classifier (108) that has been trained to predict passenger loads at vehicle stops on a transportation route, based on reconstructed passenger loads for vehicle stops on the road. Transaction data is acquired for passengers embarking at vehicle stops on the transport route. Rebuilt passenger loads are calculated for on-road vehicle stops based on the transaction data. With the trained classifier (108), a passenger load for at least one of the vehicle stops on the haul road is predicted, based on the rebuilt passenger load for the vehicle stop.
    公开号:FR3071647A1
    申请号:FR1858354
    申请日:2018-09-17
    公开日:2019-03-29
    发明作者:Sofia Zaourar Michel；Frederic Roulland；Joseph Rozen
    申请人:Conduent Business Services LLC；
    IPC主号:
    专利说明:

    ® PREDICTION OF ACTUAL LOADS FROM PRICE COLLECTION DATA.
    FR 3 071 647 - A1 (57) A system and a method are provided for predicting passenger loads at vehicle stops on a transport network. The method includes providing a classifier (108) which has been trained to predict passenger loads at vehicle stops on a transport route, based on reconstructed passenger loads for vehicle stops on the route. Transaction data is acquired for passengers who embark at vehicle stops on the transport route. Reconstructed passenger charges are calculated for vehicle stops on the road based on transaction data. With the trained classifier (108), a passenger load for at least one of the vehicle stops on the transport route is predicted, based on the reconstructed passenger load for the vehicle stop.
    1-Tl
    The example embodiment relates to transport planning and finds particular application in a system and method for predicting passenger load on a transport network.
    [0002] In transport networks, information on the passenger load between stops can be used by transport planners to determine whether the transport network meets the needs of its users and to modify programs, capacity vehicle, and the like to provide an appropriate level of service in a cost-effective manner.
    Traditionally, information on the passenger load has been obtained manually, by placing observers on vehicles or at stops or by using household surveys or roadside interviews. However, it is an expensive and time-consuming process for collecting data. More recently, vehicles have been provided with the ability to collect passenger information, for example through automatic ticket validation (ATV) systems. However, these systems tend to give an incomplete picture of passenger occupancy of a vehicle. Many of these systems generally only detect passenger boarding, for example, when passengers scan an ATV machine with a ticket. Descents on the other hand must usually be deducted from subsequent validations for travelers, or be followed by anonymized ticket numbers, during a day of operations. A set of heuristics can be used, which takes into account the fact that some passengers make journeys in several sections, getting off at one stop and boarding another before ending their journey and that passengers generally return to the origin of their first trip of the day at the end of the day.
    To estimate the number of passengers traveling between any two points on the network, methods have been developed, as described for example in the US publication No. 20150186792. The information can be stored in a matrix.
    However, these methods have been found to underestimate the passenger load in some cases. For example, some passengers may forget to validate their tickets or fail to buy a ticket. As a result, overloading can occur in certain vehicles, which leads to passenger dissatisfaction and potential loss of income through loss of travelers. This results in changes in traveler behavior over time. For example, the number of passengers on a particular vehicle can vary during a day, the number of travelers on the network can vary during a week, the number of individual can equivalent.
    Actual process vary from traveler to stop for hours, and system prices for a more realistic forecast from automatic data.
    There remains a need for one of and a collection of charges so
    BRIEF DESCRIPTION According to one aspect of the exemplary embodiment, a method for predicting a passenger load includes providing a classifier that has been trained to predict passenger loads at stops the base of stops of vehicle on a transport road, vehicle loads on the passenger vehicle reconstructed for road. Data on transaction boards are acquired at stops for vehicle passengers on the transport route. calculated
    From the basis for loads of data classifier driven stops, the less one of the transport stops predicted, the vehicle passenger reconstructed on the transaction route.
    With are on a passenger load for vehicle on the road based on the passenger load rebuilt for vehicle stop.
    One or more steps of the method can be implemented with a processor.
    In another aspect of the exemplary embodiment, a system for predicting a passing load includes a classifier that has been trained to predict passenger loads at vehicle stops on a transportation route, on the base of passenger charges reconstructed for vehicle stops on the road. A trip reconstruction component predicts descent stops for passenger trips on the transaction database for passengers who embark at vehicle stops on the transport route. A load reconstruction component calculates reconstructed passenger loads for vehicle stops on the road, based on boarding stops and predicted descent stops. A load prediction component uses the trained classifier to predict a passenger load for at least one of the vehicle stops on the transport route, based on the reconstructed passenger load for the vehicle stop. A processor implements the trip reconstruction component, the charge reconstruction component, and the charge prediction component.
    In another aspect of the exemplary embodiment, a method of generating a system for predicting a passenger load includes acquiring transaction data for passengers who board at stops in vehicle on a plurality of transport routes in a transport network and calculating reconstructed passenger charges for vehicle stops on the plurality of transport routes, based on transaction data. The method further comprises acquiring account data for passengers embarking at vehicle stops on the plurality of transport routes and calculating actual passenger charges for vehicle stops on the plurality of transport routes. transport, based on account data. A classifier is trained to predict passenger loads at vehicle stops on a transportation route in the transportation network.
    The training is based on the reconstructed passenger loads and the actual passenger loads on the plurality of transport routes. The trained classifier is stored in a memory to predict a passenger load for one of the vehicle stops on one of the transport routes, based on a new reconstructed passenger load for the vehicle stop.
    One or more steps of the method can be implemented with a processor.
    BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a block diagram of an environment in which a system for predicting a passenger load operates;
    Figure 2 is a block diagram of an example load prediction system;
    Figure 3 is a flowchart illustrating a method for predicting a passenger load;
    Figure 4 is a graph showing an average error (MAE) in predicted passenger loads for trips made on a transport route in a month; and [0016] Figure 5 is a graph showing an actual load (APC load), a predicted load, and a reconstructed load (FC load) at stops in a journey on a transport route.
    DETAILED DESCRIPTION [0017] A system and method for predicting passenger loads on vehicles in a transportation network are described. Predicted charges are of value to agencies that balance traveler satisfaction and operating costs. Predicted charges explain differences between reconstructed passenger charges, deducted from transaction data, and actual passenger charges on board vehicles.
    As used here, the actual passenger load at a given stop is the number of passengers on board a transport vehicle and corresponds to the number of passengers on board before arriving at the stop plus the number of passengers boarding at the stop, minus the number of passengers leaving the stop. In some cases, the actual passenger load may be an overall or average value, calculated over several journeys made by the same or different transport vehicles on the same transport route.
    If the price transaction calculation refers to FIGS. 1 and 2, a system 10 loads data analysis (sometimes called collection data which are from a network directly from data of receipts, of associated transport 14 transaction, the system or
    In r
    indirectly, using them generates predicted passenger load data 16 for one or more routes of the transport network 14, or information based thereon. Transaction data can be received by the system 10 from an intermediate data collection server (DCS) 18, which collects data from various parts of the network
    and can process data, for example, to of collect prices for traveling facts through of the network users 14. The transport network 14 may to be Phone than described, for example, in one or many of the
    publications
    20170169373,
    20160364645,
    20140201066,
    20130317742,
    U.S. No.
    20170132544,
    20160123748,
    20140089036,
    20130185324,
    20170206715,
    20170109764,
    20160033283,
    20130317884, and the request
    20170206201,
    20170053209,
    20140288982,
    20130317747,
    U.S. No. 15/151
    773, filed May 11, 2016, titled "TRAVEL DEMAND
    INFERENCE FOR PUBLIC TRANSPORTATION SIMULATION ”, by
    Boris Chidlovskii.
    For example, the transport network 14 includes multiple public transport vehicles 20, 22, etc., such as buses or trams. Vehicles travel on different routes 24, 26, etc. of the network 14, according to predefined programs, to provide transport services which are used by a large number of users, who can be called passengers or travelers. Each route can include a set of predetermined stops 28, 30, 32, etc. (such as bus stops or tram stops), at fixed locations on the road, where passengers can get in or out of a vehicle during a given vehicle trip. Each vehicle trip can start at the first stop on the road, make stops at one or more intermediate stops, and end the trip at a final stop on the road. In some cases, the last stop on a trip may be the same as the first stop on the next trip.
    Data collection units, such as automatic ticket validation devices 34, 36 in or associated with the vehicles collect transaction data 12 for each transaction with a passenger, which are sent to the data collection server 18 and / or to the load calculation system 10, for processing. The ATV device 34, 36 may include a radio frequency identification transaction tag (RFID) which collects transaction data 12 for travelers. Each vehicle 20, 22 may include one or more automatic ticket validation devices 34, 36, for example, mounted in the passenger area of the vehicle or the door through which passengers enter or exit the vehicle. In some embodiments, the automatic ticket validation devices 34, 36 may be located at or near stops on the transportation route, for example, on platforms or at entry doors. The transaction data 12, generated by the automatic ticket validation devices 34, 36, is collected by the data collection system 18, and can be used, in some cases, to bill passengers for their trips.
    One or more of the vehicles 20 can be equipped with an automated passenger counter (APC) 38, which detects passengers entering and / or leaving the vehicle. Each detection of a person is associated with a respective time stamp. Account data 40 is sent to the system 10 from the automated passenger counter 38, which links accounts to vehicle stops on a vehicle trip by comparing the timestamps of the accounts and observed vehicle downtime. Automated passenger counters can operate using infrared lights above vehicle doorways. A set of infrared beams is spaced so that the order in which the beam is cut by a person determines whether they enter or leave the vehicle. Alternatively, closed circuit television cameras can be used, with intelligent person counting software, to record the number of people getting on and off at each stop.
    Vehicles on a road or on the network do not necessarily have to all be equipped with an automated passenger counter 38. Automated passenger counter systems can be costly to maintain and operate. Equipped vehicles can make numerous journeys along the different routes in the network and the data collected can be assimilated and analyzed before passenger charges are available. In other embodiments, the account data is obtained by persons assigned to count the number of passengers entering and leaving the vehicle at each stop. Account data 40 for each of a set of down times is then sent to the system. The people who do the counting can be in the vehicles or placed at the stops.
    In the present system and method, the transaction data 12 are used to predict the passenger load 16 at or between one or more stops on the route or routes 24, 26, in particular, for stops where it does not exist. there is no account data 40 available, by learning a relationship between the observed account data 40 and the reconstructed load data 42 deduced from the transaction data 12.
    Predicted charges 16 may differ from reconstructed charges 42, generated from transaction data 12. The difference may be for a variety of reasons: some travelers may be allowed to embark without registration, for example, because they hold passes which allow them to travel without tickets. Others may forget to register or intentionally avoid registering. Some passengers may use single-use tickets or other tickets, such as paper tickets, which are not observed by the system.
    The automatic ticket validation devices (ATV) 34, 36 and the counters 38 can deliver the transaction data 12 and the account data 40 to the data collection system 18 and / or to the system 10 by a wired connection. or wireless 44. Different methods of data transfer 12, 40 are provided, for example via a wide area network, such as the Internet, using intelligent user peripherals 46 such as relay devices (see for example, US publication no.
    20140201066), via a local area network or direct connection when the vehicle is returned to its basic location, or via short-range communication when the vehicle is within range of a fixed communication device 48, which can be positioned at or near one or more of the stops 28, 30, 32, etc. The fixed communication device 48 can transmit data to the system 10 of will be appreciated, limited to the wired or wireless manner. As this method is only for collecting transmitting data 12, 40 and more than one method the system and the methods used not and can be used.
    In one embodiment, at least some users of the transport network pre-register with the data collection system 18 or with another recording system. The user is provided with an electronic ticket 50, which allows the user to make trips on the network and to pay for the trips, for example, by withdrawing a respective amount from a value recorded on the card or by debiting the user's credit card. The electronic ticket 50 can be in the form of a physical card, for example, with an RFID chip, or can be in the form of a software application on the intelligent peripheral 46, which is equipped with a short communication device scope. When the user scans the automatic ticket validation device 34, 36 with the smart card or the telephone 46, the automatic ticket validation device determines whether the ticket is valid for the journey and, if validated, generates transaction data 12 for a transaction.
    In some cases, a unique identifier (user identification) 52 is associated with each of the registered users, which can be registered on the electronic ticket 50. Other network users can use a prepaid ticket 50, which allows a user to add an amount to the ticket anonymously. The ticket 50 can have a unique identifier 52 which is deduced as being associated with journeys made by the ticket holder and can be treated in the same way as a user identification for analysis purposes.
    In certain embodiments, the automatic ticket validation device (ATV) 34 and the automated passenger counter (APC) 38 can be incorporated into a common data collection unit in the vehicle which delivers the account data. and transaction data.
    Each time a user scans an automatic ticket validation device 34 with his electronic ticket 50, information passes between the electronic ticket 50 and the automatic ticket validation device, for example by short-range communication , such as close field communication, and if the electronic ticket 50 is valid (for example for the route and / or the time), transaction data 12 are generated. The transaction data 12 may include some or all of the ticket / user identification 52, a transaction timestamp 54, location data 56, and a vehicle identifier / automatic ticket validation 58. The data 12 issued are sufficient to identify stop 30 on the scheduled route where the respective passenger has boarded the vehicle.
    The location data 56 can be generated using an automated vehicle location device (AVL) 60 on board the vehicle 20. In one embodiment, the automated vehicle location device includes a GPS system on the vehicle. vehicle, which communicates with a satellite 62 to identify the location of the vehicle at each stop. Alternatively, the automated vehicle location device acquires location information from fixed beacons 48 at stops, each of which transmits a respective location to the vehicle when it is in the communication field. Such a system is described, for example, in U.S. publication No. 20170206715, published July 20, 2017, titled "LOCALIZATION OF TRANSACTION OF TAGS", by Remi Feuillette, realization, des and others. In other forms of automatic 34, 36 along the route, ticket validation ticket validation devices are in a fixed location, 56 of the device can be associated with the electronic ticket 50 ticket validation device.
    Automatic location when user swipes ticket
    In some forms of the network system does not receive
    14, the automatic data data with realization, where of the location of the location 56 can be generated by the system 10, for example, by comparing the transaction time stamp 54 with programmed stop times at each stop for the route , which can be stored in a route program 64.
    The time stamp 54 can be produced by a clock forming part of or associated with the automatic ticket validation device 34. The clock can be periodically synchronized with precise time information provided by the fixed tags 48 at stops , each of which transmits a respective time signal to the vehicle when it is in the communication field. The automated vehicle location device 60 may also include a clock which provides time stamps for each of the stops. The automated vehicle location clock can be synchronized periodically with the automatic ticket and / or tag validation clock (s). The transaction timestamps 54 may differ from the downtime provided by the automated vehicle location device 60, depending on whether the transaction takes place before or after boarding.
    The vehicle identification / automatic ticket validation 58 can be used to associate the vehicle with the other transaction data 12 and the account data 40.
    The account data 40 can be calculated by the automated passenger counter 38, keeping an account in progress of the total number of passengers on board the vehicle, based on the detected movements of people in and out of the vehicle. In other embodiments, the account data 40 may simply be raw passenger detection data which is collected and sent to the system 10. In some embodiments, each passenger entry / departure may be associated with a timestamp. The automated passenger counter account data 40 thus allows the actual passenger load 66 (automated passenger counter data) at a given stop to be determined.
    If we continue to refer to Figure 2, the load calculation system 10 includes a memory 70, which stores instructions 72 for the implementation of the example method, and a processor 74, communication with the memory, to execute the instructions. In particular, the processor 74 executes instructions for the implementation of the overall processor of the memory instructions 70. computer can
    The method described in also ordering computer processing 10 which are computer system also includes FIG. 3. The operation execution by stored in implemented by the by one or more input-output interfaces (I / O) 76, 78 for communicate with external devices, such as the data collection system 18 and / or the network 14, for example via a link 80, such as a wired or wireless network, such as the Internet.
    The input-output interface 76 receives as input the transaction data (FC) 12 and the account data 40 for one or more routes of the network for each of a set of vehicle trips. I / O interface 78 can deliver predicted passenger load data 16, or information based thereon, to an output device 82, such as a display device, a printer, a computing device client, incorporating one or more of a computer incorporating memory and processor, a display device for displaying information for users, and a user input device for entering text and / or for communicating user-entered information and command selections to the processor, which may include one or more of a keyboard, numeric keypad, touch screen, writable screen, and a cursor control device, such as a mouse, a trackball, or the like. The various hardware components 70, 74, 76, 78 of the system 10 can all be connected by a bus 84. The system 10 can be hosted by one or more computer devices, such as the server computer illustrated 86.
    The computer system 10 may include one or more of a personal computer, such as a desktop device, pocket, a computer, a laptop computer, a server assistant computer, portable digital (PDA), a cell phone, a tablet, a receiver thereof, or another message, a combination computer device capable of executing instructions for the implementation of the example method.
    The memory 70 can represent any type of non-transient computer-readable medium such as random access memory (RAM), read-only memory (ROM), a magnetic disk or tape, an optical disk, a writable memory or holographic memory. In one embodiment, the memory 70 includes a combination of random access memory and read-only memory. In some embodiments, processor 74 and memory 70 can be combined into a single chip. Input / output (I / O) interfaces 76, 78 allow the computer to communicate with other devices via a computer network, such as a local area network (LAN) or a wide area network. (WAN), or Internet, and can include a modulator / demodulator (MODEM), a router, a cable, and / or an Ethernet port. The memory 70 stores instructions for implementing the example method as well as the processed data, such as actual passenger load data (automated passenger counter data) 66 and predicted passenger load data 16.
    The digital processor 74 can take different forms, such as a single-core processor, a dual-core processor (or more generally a multi-core processor), a digital processor and a mathematical coprocessor of cooperation, an equivalent circuit.
    The term "software", intended to encompass any digital control, or as used herein, is what collection or set of instructions can be executed by a computer or other digital system in order to configure the computer or other digital system to perform the task that is the object of the software. The term "software" as used herein is intended to encompass instructions stored in a storage medium such as random access memory, hard drive, optical disc, and so on, and is also intended to include what this is called "micro-software" which is software stored in a read-only memory and so on. Such software can be organized in different ways, and can include software components organized in the form of libraries, Internet-based programs stored on a remote server and so on, source code, interpretive code, object code, directly executable code, and so on. It is expected that the software may involve code at the system level or call other software on a server or other location to perform certain functions.
    The software instructions 72 may include different components for implementing parts of the method. In some embodiments, some or all of the software components may be totally or partially resident on the client device 82 and / or the data collection system 18.
    The illustrated software instructions include a passenger trip reconstruction component 90, a load reconstruction component FC 92, an automated passenger counter load calculation component 94, a drive component 96, a component load prediction 98, an optional network modification component 100, and an output component 102.
    The passenger travel reconstruction component 90 calculates embarkation and descent data 102 for each route 24, 26 in the network 14 (or for at least certain routes), on the basis of transaction data 12. The embarkation and descent data 102 includes the number of embarkations at each stop along each route for a given trip and the expected number of descents at each stop, based on transaction data (FC).
    The trip reconstruction component 90 first processes the transaction data 12 to associate each recorded transaction with a boarding stop on a given route during a given vehicle trip. The method of identifying the boarding stop may vary, depending on the information provided in the transaction data 12. For example, in certain cases, for example when the automatic ticket validation device 34 is at a fixed location, for example, at the stop location, the stop location can be included in the transaction data for the passenger journey. In other embodiments, the boarding stop can be inferred from the time stamp 54 of the transaction and / or associated location data 56. For example, observed downtime for vehicles on a road can be compiled from the recorded transaction data 12 and / or can be extracted from the automated vehicle location data 60. These observed stop times can be grouped in a sequence of stop times which are aligned with stop times. Theoretical stops for the scheduled trip, which are available from route program 64. The planned transport services for each route in network 14 can be described in GFTS (General Transit Feed Specification) format files distributed to the public, which can be used or adapted for use as a route program
    Each associated with a particular stop passenger boarding and thus can be a theoretical stop time.
    Since available for reconstruction the descents are not heuristics collected from the travel network 90
    104 to data generally not the component of a set
    14, applies transaction 12, each passenger throughout a day, or for another appropriate duration, to predict a descent associated with each embarkation of identified passenger. The passenger is assumed to be the same if the same user ID or ticket ID 50 is used in more than one transaction on the network. The example heuristics 104 may include some or all of:
    1. Users return to their previous travel destination stop for their next trip, or to the nearest stop on the next route, that is, users get off at the nearest stop of the next boarding stop in their history of the day.
    2. The users generally have a symmetrical use of the network, that is to say that the first embarkation of the day is the final destination of the same day (or the day before), assuming that it is possible, given the route chosen for the last embarkation. A day can be defined as a 24-hour period starting at midnight, or some other predefined time.
    3. For users making only one embarker during the day, the descent can be assumed to follow a descent distribution which is the same as users with multiple embeddings (or as a variant these embeddings can be ignored).
    4. The descent stops for travelers without electronic tickets 50, such as those using single trip tickets (comprising tickets with multiple journeys) follow a distribution similar to those using smart cards in their embarkations and descents.
    Methods of applying heuristics to link embarkations to descents on the same route are described, for example in US publication n ° 20130317884 and US publication n ° 20130317742 mentioned above, and the US application No. 15/788,334, filed October 19, 2017, entitled "GOAL-BASED TRAVEL RECONSTRUCTION", by Joseph Rozen, et al. Other heuristics can be used in addition to or instead of these. The goal is to associate each passenger boarding stop, identified from the transaction data, with a respective descent stop on the same route and the same vehicle journey. Boarding and alighting data can be aggregated for passengers in the same vehicle journey to identify the number of enplaned and alighted passengers at each stop. In some cases, the data may be aggregated over several days, for example for the same scheduled travel time, and may then be averaged to provide average daily numbers of passenger boarding and alighting.
    The load reconstruction component FC 92 involves a reconstructed passenger load 42 between a pair of stops, on a given service along a route, on the basis of embarkation and descent data 102. This may include, for each stop in sequence along the route, starting from the first, the calculation of the reconstructed passenger load (FC load) in the form of a sum:
    Passenger load = number of passengers already on board + number of passengers boarding - number of passengers getting off (1) For the first stop, the number of passengers on board can be assumed to be zero, unless the route is a continuous route in which passengers can enter and exit at any stop. Similarly, for the last stop, only one descent can be allowed, so that the passenger load can be set to zero, except in the case of the continuous route.
    The automated passenger counter load calculation component 94 calculates the actual passenger load 66 in a similar manner, but in this case using the boarding and alighting accounts in the account data 40. As note that the automated passenger counter data may only be available for a limited number of downtimes on a given day, allowing vehicles fitted with an automated passenger counter device 38 to revolve around the network to collect accounts for different routes during the month.
    The drive component 96 drives a classifier 108 intended to predict the passenger load data 16. The drive component 96 learns parameters of a classifier model in order to minimize, on all the data d 'drive 66, 42, the difference between each reconstructed passenger load 42 and the respective passenger load 66 for each stop on the road. The classifier may include one or more models of classifiers 110, 112, etc. In an exemplary embodiment, a secondary classifier model 110 is trained for each route 24, 26, if sufficient training data is available. A global classifier model 112 can be trained on training data for a number of routes, such as two or three or more routes. The different secondary models 110, 112 are combined in a single hierarchical classifier model 108.
    The classifier model or models may each be a (multiple) linear regression classifier which is trained to optimize (for example minimize), over the whole of the training, a loss function which takes as input the actual passenger load 66 and the respective reconstructed passenger load 42 (and / or one or more other factors) for each of a set of vehicle stops on the road or the entire network. In training, parameters θ η are learned for a weighting of each of the factors F n , where n is the number of factors. The loss to be minimized is therefore a function, over a set of N training samples, of a difference between the real passenger load APCL and a predefined function f of the set of factors weighted with the parameters θ η F n . The function f may simply be the sum of the set of factors weighted with the parameters, may include additional terms, such as a polarized term, or may be a more complex function. The parameters θ η can be scalar values or values drawn from probability distributions (which can be quantified in a set of lots).
    As will be appreciated, rather than minimizing a loss function, we can have a function which maximizes a similarity between APCL and the predicted passenger load calculated with function f.
    The classifier model (s) can be trained using, as input, the actual load data 66 for a given stop and some or all of the following factors F n :
    1. FC load: the passenger load reconstructed for the given vehicle stop on the transport route.
    2. FC load at previous stop time: the reconstructed passenger load for the immediately preceding vehicle stop on the transport route (which can be set to zero when the given vehicle stop is the first stop on the route ).
    3. FC boarding: an estimated number of passengers boarding at the given vehicle stop on the transport route, extracted from transaction data for the given stop.
    4. Aggregated FC shipments for vehicle travel: an aggregate of the estimated numbers of passengers boarding the vehicle at all vehicle stops on the road.
    5. HR load squared, or another non-linear function of the passenger load reconstructed for the given vehicle stop on the transport route (to capture certain residual elements).
    In general at least two or at least three, or at least four of these factors (predictive factors) F n are used. Classifier training includes learning a respective parameter (or set of parameters) θ η for each of the factors. As an example, the classifier models are driven by a Bayesian hierarchical multiple linear regression. See, for example, Mallick, et al., "Bayesian Methods For High Dimensional Linear Models", J Biom Biostat, 1, pages 1 to 27, 2014; Raudenbush, et al., "Hierarchical linear models: Applications and data analysis methods", vol. 1, Sage, 2002; Albert, et al., "Bayesian Analysis of Binary and Polychotomous Response Data" J. Am. Statistical Assoc., Vol. 88, n ° 422, pages 669 to 679 (June 1993). The Bayesian hierarchical multiple linear regression classifier used parameters taken from one can be learned as part In another embodiment, distribution, which of training.
    fixed value are used, with the same parameters set of factors.
    The classifier hierarchical nature of example of the route model, given by specific to a classifier, the for route allows to learn in Grouping model parameters from the to a route of each group does
    Their values and specific parameters are not learned individually, constrained by a normal distribution which is learned with respect to the global model 112. As an example, the implementation of PyStan (https://pystan.readthedocs.io/en/latest/ ), which is based on the software used for classifier
    Stan (http://mc-stan.org/), generate and put in hierarchical Bayesian regression.
    The classifier model can be used with multiple linear
    108 is thus trained to take, as input, load of passenger loads reconstructed 42 passenger when insufficient) of data a route, for there are no stops and no (or actual load data predict vehicle for the trip.
    The load predictor component the driven classifier 108 for predicting one or more of a vehicle trip vehicle trips on passenger load data 16 for a scheduled vehicle in for an aggregate of the same route), based reconstructed passenger 42.
    of them on available way of uses loads stops la of Optional proposal component 100 can use the predicted load data to mark potential problems in network 14. For example, if the passenger load reaches or exceeds a predetermined threshold for one or more stops of a vehicle trip, the proposal component 100 can issue an alert. Or it may suggest changes to the network, such as adding additional vehicle trips, where a calculated cost-benefit analysis suggests it would be beneficial. The cost-benefit analysis may take into account the usefulness for passengers of not traveling in crowded vehicles and, in some cases, the fact of not being able to board the vehicle.
    The output component 102 delivers information, such as predicted passenger load data 16 or information generated therefrom, such as alerts / proposals generated by the network modification component 100.
    As will be appreciated, the drive component 96 may be part of a separate system or removed from the system 10 when a drive is completed.
    Referring now to Figure 3, a method of calculating a passenger load which can be achieved with the system of Figures 1 and 2 is shown. The process starts in S100.
    In S102, transaction data 12 and account data 40 are acquired from a transport network, which must be used in training the classifier 108. The data 12, 40 can be stored in the memory 70 during processing.
    In S104, the transaction data 12 is processed by the trip reconstruction component 90, using the heuristics 104, to generate boarding and descent data 102 for passenger journeys, which can be stored. in memory 70 during processing. This may include predicting descent stops on the route for detected passengers, based on other (earlier and / or later) boarding stops on the same route or other routes in the network. transport detected for at least some of the passengers detected.
    In S106, the embarkation and descent data 102 are processed, by the load reconstruction component 92, to generate reconstructed passenger load data 42, which can be stored in the memory 70 during the processing.
    In S108, the account data 40 is processed, by the load calculation component 94, to generate actual passenger load data 66, which can be stored in memory 70 during processing.
    In S110, the classifier 108 is driven, by the drive component 96, with drive data composed of actual passenger load data 66 and corresponding reconstructed passenger load data 42 and / or factors derived therefrom. The parameters learned from the classifier model (s) 110, 112, 108 can be stored in the memory.
    In S112, new transaction data 120 are received by the system, these can be acquired for a vehicle trip for the same route or a different vehicle route for which the drive transaction data 12 are acquired, but are generated in the same way.
    In S114, step S104 is repeated, with the new transaction data 120.
    In S116, step S106 is repeated, with the boarding and descent data 102 generated in S114 from the new transaction data 120, to obtain reconstructed passenger load data 42.
    In S118, the passenger load data 42 and / or the factors generated therefrom are entered into the classifier 108, thanks to the load prediction component.
    Optionally, in S120, a determination can be made as to whether the predicted passenger load data calculated in S118 exceeds a threshold and, if so, an alert can be issued or the load data can be marked with another way. Alternatively or may additionally, a user review the passenger load data has been issued by the time it (S122).
    The process
    The process works in ends illustrated in S122.
    in Figure 3 can be computer program computer. The product of comprising a non-transient computer support a product which can be executed on a computer program can of recording readable by i on which a control program is recorded (stored), such as a disk, hard disk, or equivalent . Alternatively, the method can be implemented in transient media, such as a carrier wave that can be transmitted in which the control program is incorporated as a data signal using transmission media, such as waves acoustic or light, such as those generated during radio and infrared wave data communications, and the like.
    The example method can be implemented in one or more computers for general use, one or more computers for special use, a programmed microprocessor or microcontroller and peripheral integrated circuit elements, an ASIC type circuit or another integrated circuit, a digital signal processor, a wired electronic or logic circuit such as a discrete element circuit, a programmable logic device such as PLD, PLA, FPGA, central graphics card (GPU), or PAL , or equivalent.
    The present method allows agencies to view loads on board vehicles, with credible intervals.
    As an illustrative example of the method, it is assumed that training data is acquired to include a sequence are identified by street or route names 1 on five number stops in Figure 1, which
    28, 30, etc. , which at 5 (although may be the names given the one of the ones used in a way
    Table 1 shows which can be the number obtained and general locations for the type of generated. FC boarding is who board at each stop, as that of passengers is determined from the price collection data 12 for a vehicle trip (or an average of a set of vehicle trips) along the route. The FC descent is the number of passengers expected to alight at each stop for the vehicle journey, based on the analysis of price collection data 12 for passengers on the entire network, using heuristics. The FC load is the reconstructed passenger load, which in this case is obtained by applying equation 1 for each stop in sequence, using the respective FC boarding and descent FC values. APC boarding and descent APC are the accounts obtained from the automated passenger counter sensor 38. The APC load is the actual passenger load obtained by applying equation 1 for each stop in sequence, using the APC boarding and APC descent values respectively. The predicted load values are illustrative of values (rounded to the nearest integer) that could be obtained by training a classifier model on the FC load and the APC load.
    Table 1
    Stop 1 2 3 4 5 FC boarding 4 3 7 2 0 Downhill FC 0 0 2 5 9 Charge FC 4 7 12 9 0 APC boarding 5 3 9 2 0 APC descent 0 0 3 4 12 APC charge 5 8 14 12 0 Factors used in theprediction: FC load,FC boarding,previous FC load stop,boarding FCaggregate, FC squared load 4,4,0,16.16 7,3,4,16.49 12,7,7,16144 9,2,12,16, 81 0,0,9,16.0 Predicted load 6 8 13 12 1
    Without planning to limit the scope of the exemplary embodiment, the following example illustrates an application of the method. a public transport network in a French city.
    EXAMPLE Data was obtained from three operational sources: transaction data from automatic ticket validation devices, automated vehicle location data, and automated passenger counter data to reconstruct charges for vehicles in a public transport network and then predict actual loads from those observed.
    Similar models, although with different predictive factors, could be trained to predict embarkations and / or total descents.
    To reconstruct the passenger loads on board vehicles from the transaction data 12, transaction events are extracted from the transaction data, normalized, filtered and linked to known stops on the public transport network. a city, available in a set of GTFS files. These transactions are linked to observed downtime, obtained from the automated vehicle location system, when available. Individual embarkations and descents calculated from transaction data are aggregated to generate embarkations, descents and FC load accounts for these downtimes.
    Boardings, descents and actual loads observed by the automated passenger counter system can then enrich downtime. When there are differences between the AVL and APC clocks in a vehicle on a given day, the data of the two is first synchronized. This includes calculating a time difference between the two data sets by calculating all the time differences, getting rid of the aberrations, and averaging the time difference for what remains. The average time difference is then applied to the automated passenger counter timestamps. If necessary, automated passenger counter stop times with boardings at the end of the routes are divided into two separate stop times, one with descents to complete the trip and one with boardings to start a new one.
    When the synchronized time stamps of the automated passenger counter are close to the automated vehicle location stop times (for example 120 seconds), the automated vehicle location stop times are enriched with the passenger counter data. automated. In this way, some of the downtime is enriched with actual loads calculated from the automated passenger counter data.
    The accounts reconstructed via the price collection data are different from those obtained from the automated passenger counter systems. In the transport network of the city studied, some travelers use paper tickets which are not visible to the system. It is also possible that some of the differences could be due to negligent or intentional misuse of the automatic ticket validation devices. Additionally, the automated passenger counter data is only available for a limited number of downtimes on a given day, due to the fact that equipped vehicles turn to collect accounts for routes during the month.
    A classifier model is trained to predict total charges using the reconstructed and actual charge data, when available. A trained linear multiple regression classifier model with a Bayesian hierarchical predictor was grouped on the road and following the FC load, FC load at previous downtime, FC boardings, FC boardings aggregated for the trip and FC load at the square to capture certain residual elements.
    Figure 4 shows the mean absolute error (MAE) for predicted loads in road trips in a given month. Results show an overall mean absolute error of less than 4 for load predictions, using automated accounts from onboard automated passenger counter devices in vehicles selected for classifier training. As can be seen, a trip is a substantial aberration, with an EAW of more than 10, which suggests the advantage of aggregating trip data over several days.
    FIG. 5 is an example trip on a road on the transport network, the dark part showing the credible interval at a probability of 0.5 and the lighter part showing the credible interval at a probability of 0.9. As can be seen from Figure 5, the predicted loads are almost always closer to the actual load (APC load) than the reconstructed load (FC load) for each stop.
    The results suggest that intelligent transport systems, which generally include multiple vehicles, roads, and services which are used by a large number of users and which include automatic ticket validation systems which collect validation information for travelers, should benefit from the present system and procedure. Administrators can improve the management and planning of these transport systems, for example by adding additional routes, increasing the number of buses or trains on a route, increasing the size of
    权利要求:
    Claims (16)
    [1" id="c-fr-0001]
    X. A method for predicting a passenger load, characterized in that it comprises:
    provide a classifier (.1.0-8) which has been
    5 driven to predict passenger loads at vehicle stops on a transport whole, based on reconstructed passenger loads for vehicle stops on the road;
    acquire transaction data for 10 passengers who board vehicle stops on the transport route;
    with a processor (74), calculating reconstructed passenger charges for vehicle stops on the road based on transaction data; and
    15 with the trained classifier (108) predicting a passenger load for at least one of the vehicle stops on the transport route, based on the reconstructed passenger load for the vehicle stop.
    20
    [2" id="c-fr-0002]
    2. The method of claim 1, wherein the classifier (108) is trained with actual passenger loads for respective vehicle stops on the road and a plurality of factors, the plurality of factors including the reconstructed passenger load for 25 a given vehicle stop on the transport route, preferably where the classifier (108) is a Bayesian hierarchical multiple linear regression classifier.
    [3" id="c-fr-0003]
    3. Method according to claim 2, according to which at least one factor from the plurality of factors is chosen by:
    the passenger load reconstructed for a previous vehicle stop on the transport route;
    an estimated number of passengers boarding at the given vehicle stop on the transport route, the estimated number being based on transaction data;
    an aggregate of estimated numbers of passengers boarding at vehicle stops; and a non-linear function of the passenger load reconstructed for the given vehicle stop on the transport route,
    [4" id="c-fr-0004]
    4. Method according to any one of the preceding claims, according to which the fact of providing the classifier involves training the classifier, preferably by co-supporting. in addition to acquiring accounts of passengers who embark and alight at vehicle stops on at least one road of a transport network and respective reconstructed passenger charges for vehicle stops.
    [5" id="c-fr-0005]
    5. Method according to any one of the preceding claims, in which the acquisition of transaction data for passengers who board at vehicle stops on the transport route comprises the acquisition of identifiers for electronic tickets used by at least some of the passengers who board at the vehicle stops.
    [6" id="c-fr-0006]
    6. Method according to any one of the preceding claims, according to which the calculation of the reconstructed passenger loads comprises the fact of predicting descent stops for passengers, on the basis of other boarding stops on routes of transport network for at least some of the passengers.
    [7" id="c-fr-0007]
    7. Method according to any one of the preceding claims, according to which the calculation of the reconstructed passenger loads comprises the fact of predicting descent stops for the passengers, the forecast comprising the fact of applying a set of heuristics.
    [8" id="c-fr-0008]
    8. Method according to any one of the preceding claims, according to which the calculation of the reconstructed passenger charges comprises, for each vehicle stop in a vehicle stop sequence on the road, the fact of calculating a sum of one number of passengers already on board the number plus a number of passengers boarding minus a number of passengers descending.
    [9" id="c-fr-0009]
    The method according to any of the preceding claims, further comprising providing at least one of the predicted passenger load and information based thereon.
    [10" id="c-fr-0010]
    10. A computer program product comprising a non-transient recording medium which stores instructions which, when executed on a computer, cause the computer to implement the method according to any one of the preceding claims.
    [11" id="c-fr-0011]
    11. System intended to predict a passenger load, characterized in that it comprises:
    a classifier (108) that has been trained to predict passenger loads at vehicle stops
    D t
    1Q on a transport route, based on reconstructed passenger loads, fear of vehicle stops on the road;
    a trip reconstruction component (90) which predicts descent stops for passenger trips on the transaction database, for passengers who board vehicle stops on the transport route;
    a charging reconstruction component (92) which calculates loads passenger reconstructed for judgments of vehicle on the road, on the basis of f boarding stops and stops lowering predicted;
    a load prediction component (98) which uses the trained classifier to predict a passenger load for at least one of the vehicle stops on the transport route, based on the reconstructed passenger load for the vehicle stop; and a processor (74) which implements. performs the trip reconstruction component (90), the charge reconstruction component (92), and the charge prediction component (98),
    [12" id="c-fr-0012]
    The system of claim 11, further comprising a drive component (96) which drives the classifier based on reconstructed passenger loads for vehicle stops in a transportation network that includes the transportation route and data of actual passenger load based on passenger accounts which board and alight at respective vehicle stops, preferably comprising. besides one. automated passenger load calculation component that calculates actual passenger load data based on passenger accounts that board and alight.
    [13" id="c-fr-0013]
    13. System according to claim 1, comprising, in addition, an output component {102} which delivers the predicted passenger load or information based thereon.
    [14" id="c-fr-0014]
    The system according to any of claims 11 to 13, wherein the trip reconstruction component {90} predicts descent stops for passenger trips using a set of heuristics>
    [15" id="c-fr-0015]
    15. Method for generating a system according to any one of claims 11 to 14 intended to predict a passenger load, characterized in that it comprises the fact of:
    15 Acquire transaction data for passengers who embark at vehicle stops on a plurality of transport routes in one. transportation network;
    calculating reconstructed passenger charges for vehicle stops on the plurality of transport routes, based on the transaction data;
    acquiring account data for passengers who embark at vehicle stops on the plurality of transport routes;
    Calculating actual passenger charges for vehicle stops on the plurality of transport routes, based on the account data;
    training a classifier (108) to predict passenger loads at vehicle stops on a transport route in the transport network,
    The drive being based on the reconstructed passenger loads and the actual passenger loads on the plurality of transport routes;
    storing the classifier trained in memory to predict a passenger load for one of the vehicle stops on one of the transport routes, based on the new passenger load reconstructed for the vehicle stop.
    [16" id="c-fr-0016]
    16. A system comprising a memory which stores instructions for implementing the method according to any one of claim 1 to 9 or claim 15 and a processor (74), in communication with the memory, which executes the instructions.
    类似技术:
    公开号 | 公开日 | 专利标题
    US8977496B2|2015-03-10|System and method for estimating origins and destinations from identified end-point time-location stamps
    Trépanier et al.2007|Individual trip destination estimation in a transit smart card automated fare collection system
    US9997071B2|2018-06-12|Method and system for avoidance of parking violations
    US10430736B2|2019-10-01|System and method for estimating a dynamic origin-destination matrix
    FR3033066A1|2016-08-26|
    Uniman et al.2010|Service reliability measurement using automated fare card data: application to the London underground
    US10740682B2|2020-08-11|Sensor based truth maintenance
    US20170169373A1|2017-06-15|System and method for measuring perceived impact of schedule deviation in public transport
    FR3071647A1|2019-03-29|PREDICTION OF REAL LOADS FROM PRICE COLLECTION DATA
    Yazici et al.2016|Modeling taxi drivers’ decisions for improving airport ground access: John F. Kennedy airport case
    Ridgeway2009|Cincinnati Police Department Traffic Stops: Applying RAND's Framework to Analyze Racial Disparities
    Carrel et al.2017|The San Francisco Travel Quality Study: tracking trials and tribulations of a transit taker
    Yang et al.2017|Modeling taxi demand and supply in New York city using large-scale taxi GPS data
    WO2016077677A1|2016-05-19|Business fleet scheduling and transport logistics
    JP5951903B2|2016-07-13|Fee refund system and method
    US20150081574A1|2015-03-19|System and method to gather, correlate, analyze, and report information
    FR3048840A1|2017-09-15|
    US20190266897A1|2019-08-29|Drone usage in connected user and connected fleet communication and interface systems
    Massobrio et al.2019|Urban data analysis for the public transportation system of Montevideo, Uruguay
    Ma et al.2019|Public transportation big data mining and analysis
    WO2022012241A1|2022-01-20|Information processing method, apparatus, device and system
    Brakewood et al.2020|An evaluation of the benefits of mobile fare payment technology from the user and operator perspectives
    Chu2010|Leveraging data from a smart card automatic fare collection system for public transit planning
    US11049054B1|2021-06-29|Utilizing a machine learning model to crowdsource funds for public services
    Guintran et al.2006|Systems for the early detection of malaria epidemics in Africa: an analysis of current practices and future priorities
    同族专利:
    公开号 | 公开日
    US10621529B2|2020-04-14|
    US20190095836A1|2019-03-28|
    US20190094030A1|2019-03-28|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20130185324A1|2012-01-17|2013-07-18|Xerox Corporation|Location-type tagging using collected traveler data|
    US20130317747A1|2012-05-25|2013-11-28|Xerox Corporation|System and method for trip plan crowdsourcing using automatic fare collection data|
    US20130317742A1|2012-05-25|2013-11-28|Xerox Corporation|System and method for estimating origins and destinations from identified end-point time-location stamps|
    US20130317884A1|2012-05-25|2013-11-28|Xerox Corporation|System and method for estimating a dynamic origin-destination matrix|
    US20140089036A1|2012-09-26|2014-03-27|Xerox Corporation|Dynamic city zoning for understanding passenger travel demand|
    US20140201066A1|2013-01-14|2014-07-17|Xerox Corporation|System and method for enabling transactions on an associated network|
    US20140288982A1|2013-03-19|2014-09-25|Xerox Corporation|Temporal series alignment for matching real trips to schedules in public transportation systems|
    US20150186792A1|2013-12-26|2015-07-02|Xerox Corporation|System and method for multi-task learning for prediction of demand on a system|
    US20160033283A1|2014-08-04|2016-02-04|Xerox Corporation|Efficient route planning in public transportation networks|
    US20160123748A1|2014-11-05|2016-05-05|Xerox Corporation|Trip reranking for a journey planner|
    US20160364645A1|2015-06-12|2016-12-15|Xerox Corporation|Learning mobility user choice and demand models from public transport fare collection data|
    US20170053209A1|2015-08-20|2017-02-23|Xerox Corporation|System and method for multi-factored-based ranking of trips|
    US20170109764A1|2015-10-19|2017-04-20|Xerox Corporation|System and method for mobility demand modeling using geographical data|
    US20170132544A1|2015-11-10|2017-05-11|Xerox Corporation|Method and system for stochastic optimization of public transport schedules|
    US20170169373A1|2015-12-14|2017-06-15|Xerox Corporation|System and method for measuring perceived impact of schedule deviation in public transport|
    US20170206201A1|2016-01-19|2017-07-20|Xerox Corporation|Smoothed dynamic modeling of user traveling preferences in a public transportation system|
    US20170206715A1|2016-01-19|2017-07-20|Xerox Corporation|Localization of transaction of tags|
    CN101155963B|2005-02-11|2010-12-01|托马斯·F·加斯塔夫逊|Community intermodal transit system|
    US8281990B2|2006-12-07|2012-10-09|Smart Systems Innovations, Llc|Public transit system fare processor for transfers|
    US20150242944A1|2013-09-20|2015-08-27|Eugene S. Willard|Time dependent inventory asset management system for industries having perishable assets|
    US20170357914A1|2016-06-10|2017-12-14|Conduent Business Services, Llc|System and method for optimal automated booking of on-demand transportation in multi-modal journeys|
    US20180293520A1|2017-04-06|2018-10-11|International Business Machines Corporation|Ride chaining for long distance travel|
    US10268987B2|2017-04-19|2019-04-23|GM Global Technology Operations LLC|Multi-mode transportation management|
    US20190108468A1|2017-10-10|2019-04-11|Khanh Vinh Nguyen|Method and apparatus to operate smart mass transit systems with on-demand rides, dynamic routes and coordinated transfers|CN107978022B|2017-11-03|2019-10-25|阿里巴巴集团控股有限公司|A kind of Cash collecting equipment of public transport|
    ES2822224A1|2019-10-29|2021-04-29|Univ Alicante|OPTIMIZATION SYSTEM AND METHOD FOR THE MANAGEMENT OF OPEN TRANSPORTATION MEANS |
    法律状态:
    2020-02-12| PLFP| Fee payment|Year of fee payment: 2 |
    2020-03-06| PLSC| Search report ready|Effective date: 20200306 |
    2020-09-17| PLFP| Fee payment|Year of fee payment: 3 |
    2021-08-19| PLFP| Fee payment|Year of fee payment: 4 |
    优先权:
    申请号 | 申请日 | 专利标题
    EP17306254|2017-09-22|
    EP173062548|2017-09-22|
    EP17306253|2017-09-22|
    EP173062530|2017-09-22|
    US15/788,130|US20190095836A1|2017-09-22|2017-10-19|Prediction of actual loads from fare collection data|
    [返回顶部]